The Systems Modeling Language (SysML) is a general-purpose modeling language for modeling systems that is intended to facilitate a model-based systems engineering (MBSE) approach to engineer systems. This document provides the standard specification for SysML Version 2 (SysML v2). SysML v2 is intended to enhance the precision, expressiveness, interoperability, and the consistency and integration of the language relative to SysML Versions 1.0 to 1.7 [SysML v1].

SysML v1 was specified as a profile of the Unified Modeling Language v2 [UML]. SysML v2, on the other hand, is specified as a metamodel extending the Kernel metamodel from the Kernel Modeling Language [KerML]. In order to facilitate the transition from SysML v1 to SysML v2, this standard also specifies a formal transformation from models using the SysML v1.7 profile of UML to models using the SysML v2 metamodel [SysML v1 to v2].

This document specifies the textual and graphical concrete syntax, abstract syntax, and semantics for SysML v2. The SysML v2 textual notation (see 8.2.2 ) and the SysML v2 graphical notation (see 8.2.3 ) provide the concrete syntax representation of the SysML v2 abstract syntax (see 8.3 ). The SysML v2  abstract syntax extends the Kernel abstract syntax, providing specialized constructs for modeling systems (as shown in Fig. 1 ). Further, the Systems Library (see 9.2 ) is a model library that extends the Kernel Library to provide the semantic specification for SysML v2 (see 8.4 ; see also [KerML] on the use of model libraries for semantic specification). Finally, SysML v2 provides an additional set of Domain Libraries (see 9.4 and following) to provide a set of reference models in various domains important to systems modeling (such as Analysis and Quantities and Units).

The rest of this document is organized into three major clauses.

• Clause 7 describes SysML from a user point of view. Its subclauses describe the modeling constructs in SysML, including for each a general overview, related abstract syntax diagrams and a description of the textual and graphical notation. The overviews in this clause should be considered informative. The abstract syntax and notation subclauses, however, are normative, including descriptions of the processing of the textual notation and its relationship to the graphical notation and the abstract syntax.
• Clause 8 provides the normative specification of the metamodel that defines the SysML language. This includes the concrete syntax (textual and graphical notations), the abstract syntax and the semantics for the language. The SysML abstract syntax and semantics are formally extensions of the Kernel abstract syntax and semantics provided by KerML (as discussed in 6.1 ). However, this clause does not cover details of the Kernel metamodel, which are included by normative reference to the KerML specification [KerML].
• Clause 9 specifies a set of model libraries defined in SysML itself. The Systems Library extends the Kernel Library from [KerML] in order to provide systems-modeling-specific semantics to SysML language constructs. The Domain Libraries provide domain-specific models on which users can draw when creating their own models. Each model library is described with a set of subclauses that covers each of the top-level packages in the model library, referred to as its library models.

These clauses are followed by informative Annex A , which presents an example model using the SysML language as defined in this specification to illustrate how the language features can be used to model a system.

In addition, Clause 10 of [KerML] on Model Interchange is included by reference as a normative part of this specification in order to define allowable methods for interchanging SysML models.

The primary authors of this specification document and the syntactic and semantic models defined in it are:

• Sanford Friedenthal, SAF Consulting
• Ed Seidewitz, Model Driven Solutions
• Roger Burkhart, Thematix Partners
• Eran Gery, IBM
• Hisashi Miyashita, Mgnite
• Hans Peter de Koning, DEKonsult

Other contributors include:

• Oystein Haugen, Østfold University College
• Tomas Juknevicius, Dassault Systèmes
• Charles Krueger, BigLever Software

The specification was formally submitted for standardization by the following organizations:

• 88Solutions Corporation
• Dassault Systèmes
• GfSE e.V.
• IBM
• INCOSE
• Intercax LLC
• Lockheed Martin Corporation
• MITRE
• Model Driven Solutions, Inc.
• PTC
• Simula Research Laboratory AS
• Thematix Partners LLC

However, work on the specification was also supported by over 200 people in over 80 organizations that participated in the SysML v2 Submission Team (SST), by contributing use cases, providing critical review and comment, and validating the language design. The following individuals had leadership roles in the SST:

• Manas Bajaj, Intercax LLC (API and services development lead)
• Yves Bernard, Airbus (v1 to v2 transformation co-lead)
• Bjorn Cole, Lockheed Martin Corporation (metamodel development co-lead)
• Sanford Friedenthal, SAF Consulting (SST co-lead, requirements V&V lead)
• Charles Galey, Lockheed Martin Corporation (metamodel development co-lead)
• Karen Ryan, Siemens (metamodel development co-lead)
• Ed Seidewitz, Model Driven Solutions (SST co-lead, pilot implementation lead)
• Tim Weilkiens, oose (v1 to v2 transformation co-lead)

The specification was prepared using CATIA No Magic modeling tools and the OpenMBEE system for model publication (http://www.openmbee.org), with the invaluable support of the following individuals:

• Tyler Anderson, No Magic/Dassault Systèmes
• Christopher Delp, Jet Propulsion Laboratory
• Ivan Gomes, Twingineer
• Doris Lam, Jet Propulsion Laboratory
• Robert Karban, Jet Propulsion Laboratory
• Christopher Klotz, No Magic/Dassault Systèmes
• John Watson, Lightstreet Consulting

The following individuals made significant contributions to the SysML v2 pilot implementation developed by the SST in conjunction with the development of this specification:

• Ivan Gomes, Twingineer
• Hisashi Miyashita, Mgnite
• Miyako Wilson, Georgia Institute of Technology
• Santiago Leon, Tom Sawyer
• William Piers, Obeo
• Tilo Schreiber, Siemens
• Zoltán Ujhelyi, IncQuery Labs

The System Modeling Language (SysML) contains concepts that are used to model systems, their components, and the external environment in a context. It extends the Kernel Modeling Language (KerML) as specified in the KerML specification [KerML]. SysML directly uses some elements of KerML, but most SysML elements are specializations of KerML elements.

This clause provides an informative description of all these language concepts in their context of use in SysML. Clause 8 gives the full definition of the SysML metamodel, which is the normative specification for implementing the language. In contrast, the description in this clause focuses on how the various constructs of the language are used, along with the Systems Model Library (see 9.2 ), to construct models. While non-normative, it is intended to be precise and consistent with the normative specification of the language.

SysML directly uses the following concepts from KerML:

• Elements and relationships that define the basic graph structure of a model (see 7.2 ).
• Dependencies between modeling elements (see 7.3 ).
• Annotations for attaching metadata to a model, including comments and textual representations (see 7.4 ).
• Namespaces that contain and name elements, and, particularly, packages used to organize the elements in a model (see 7.5 ).
• Specialization of elements that specify types, including subclassification, subsetting, redefinition and feature typing (see 7.6 ).
• Expressions can be used to specify calculations, case results, constraints and formal requirements. The full KerML expression sub-language is available in SysML, as described in the KerML specification. The description of this sub-language is not repeated in the SysML specification document.

The modeling constructs specific to SysML, as specified in subclauses 7.6 through 7.27 , are built on the KerML foundation, and cover the following areas:

• Fundamental aspects of constructing a model, including:
  • The general pattern of definition and usage, which is applied to many of the SysML language constructs (see 7.6 ). The pattern of definition and usage elements facilitates model reuse, such that a concept can be defined once and then used in many different contexts. A usage element can be further specialized for its specific context.
  • The modeling of variability, which includes the definition of variation points within a model where choices can be made to select a specific variant, and the selection of a particular variant may constrain the allowable choices at other variation points. A system can be configured by making appropriate choices at each of the variation points of a variability model, consistent with specified constraints. Variation points can be defined in any of the specific modeling areas listed below, so the ability to model variability is built into the base syntax of definitions and usages (see 7.6 ).
• The modeling of attributive information about things, including:
  • Attributes that specify characteristics of something that can be defined by simple or compound data types, and dimensional quantities such as mass, length, etc. (see 7.7 ).
  • Enumerations that are attributes restricted to a specified set of enumerated values (see 7.8 ).
• The modeling of occurrences with temporal and spatial extent. Temporal extent enables an occurrence to be represented at specific points in time, over a duration in time, or over an entire lifetime. Spatial extent enables an occurrence to be represented at a position and orientation with respect to a coordinate frame, and to have a shape and size (see 7.9 ).
• The modeling of individuals with specific identities (see 7.9 ).
• The modeling of structure to represent how parts are decomposed, interconnected and classified, and includes:
  • Items that may flow through a process or system or be stored by a system (see 7.10 ).
  • Parts that are the foundational units of structure, which can be composed and interconnected, to form composite parts and entire systems (see 7.11 ).
  • Ports that define connection points on parts that enable interactions between parts (see 7.12 ).
  • Connections (see 7.13 ) and interfaces (see 7.14 ) that define how parts and ports are interconnected.
  • Allocations that assign responsibility for realizing the features of one element by another element (see 7.15 ).
• The modeling of behavior, which specifies how parts interact and includes:
  • Flows of values and items between parts and actions (see 7.16 ).
  • Actions performed by a part, including their temporal ordering (see 7.17 ).
  • States exhibited by a part, the allowable transitions between those states, and the actions enabled in a state or during a transition (see 7.18 ).
• The modeling of calculations that are parameterized expressions that can be evaluated to produce specific results (see 7.19 ).
• The modeling of constraints, which specify conditions that can be evaluated as true or false, or asserted to be true or false (see 7.20 ).
• The modeling of requirements, which is a special kind of constraint that a subject must satisfy to be a valid solution (see 7.21 ).
• The modeling of cases, which define the steps required to produce a desired result relative to a subject, possibly also involving external actors, to achieve a specific objective (see 7.22 ), including:
  • Analysis cases, whose steps are the actions necessary to analyze a subject (see 7.23 ).
  • Verification cases, whose objective is to verify how a requirement is satisfied by the subject (see 7.24 ).
  • Use cases, that specify required behavior of the subject with the objective of providing a measurable benefit to one or more external actors (see 7.25 ).
• The modeling of viewpoints that specify information of interest by a set of stakeholders, and views that specify a query of the model, and a rendering of the query results, that is intended to satisfy a particular viewpoint (see 7.26 ).
• The modeling of user-defined metadata that allows for both simple tagging of elements with additional model-level information and more sophisticated semantic extension of the SysML language. In a similar way that SysML extends KerML, modelers can use this metadata capability to build domain and user-specific extensions of SysML, both syntactically and semantically. This allows SysML to be highly adaptable for specific application domains and user needs, while maintaining a high level of underlying standardization and tool interoperability. (See 7.27 .)

It should be noted that SysML does not contain specific language constructs called system, subsystem, assembly, component, and many other commonly used terms. An entity with structure and behavior in SysML is represented simply as a part (see 7.11 ). The language provides straightforward extension mechanisms to specify terminology that is appropriate for the domain of interest.

Metamodel references:

• Textual notation,  8.2.2.2
• Graphical notation, 8.2.3.2
• Abstract syntax,  8.3.2
• Semantics, none

Elements are the constituents of a model. Some elements represent relationships between other elements, known as the related elements of the relationship. One of the related elements of a relationship may be the owning related element of the relationship. If the owning related element of a relationship is deleted from a model, then the relationship is also deleted. Some of the related elements of a relationship (distinct from the owning related element, if any) may be owned related elements. If a relationship has owned related elements, then, if the relationship is deleted from a model, all its owned related elements are also deleted.

The owned relationships of an element are all those relationships for which the element is the owning related element. The owned elements of an element are all those elements that are owned related elements of the owned relationships of the element (notice the extra level of indirection through the owned relationships). The owning relationship of an element (if any) is the relationship for which the element is an owned related element (of which the element can have at most one). The owner of an element (if any) is the owning related element of the owning relationship of the element (again, notice the extra level of indirection through the owning relationship).

The deletion rules for relationships imply that, if an element is deleted from a model, then all its owned relationships are also deleted and, therefore, all its owned elements. This may result in a further cascade of deletions until all deletion rules are satisfied. An element that has no owner acts as the root element of an ownership tree structure, such that all elements and relationships in the structure are deleted if the root element is deleted. Deleting any element other than the root element results in the deletion of the entire subtree rooted in that element.

Graphically, non-relationship elements are generally represented using a box-like shape or other icon, while relationships are shown using lines connecting the symbols for the related elements. However, in some cases, additional shapes may be attached to relationship lines in order to present additional information. The specific conventions for such graphical notations are covered in subsequent subclauses.

Various specific kinds of model elements in SysML are described in subsequent subclauses. However, there are certain concepts that apply to all model elements.

Every element has a unique identifier known as its element ID. The properties of an element can change over its lifetime, but its element ID does not change after the element is created. An element may also have additional identifiers, its alias IDs, which may be assigned for tool-specific purposes. The SysML notation, however, does not have any provision for specifying element or alias IDs, since these are expected to be managed by the underlying modeling tooling. Instead, an element can be given a name and/or a short name, and it can also have any number of alias names relative to one or more namespaces (see 7.5 ).

In most cases, an element is declared using a keyword indicating the kind of element it is (e.g., part def or attribute). The declaration of an element may also specify a short name and/or name for it, in that order. The short name is distinguished by being surrounded by the delimiting characters < and >.

part <'1.2.4'> myName;

While the language makes no formal distinction between names and short names, the intent is that the name of an element should be fully descriptive, particularly in the context of the definition of the element, while the short name, if given, should be an abbreviated name useful for referring to the element. Note also that it is not required to specify either a name or a short name for an element. However, unless at least one of these is given, it is not possible to reference the element using the textual notation (though it is still possible to show it in relationships on graphical diagrams).

Names and short names can contain essentially any printable characters (and certain control characters). However, when written in the textual notation, they must be represented with a specific lexical structure, which has two variants.

1. A basic name is one that can be lexically distinguished in itself from other parts of the textual notation. The initial character of a basic name must be a lowercase letter, an uppercase letter or an underscore. The remaining characters of a basic name can be any character allowed as an initial character or any digit. However, a reserved word may not be used as a name, even though it has the form of a basic name (see 8.2.2.1.2 for the list of the reserved words in SysML).

   Vehicle
   power_line

2. An unrestricted name provides a way to represent a name that contains any character. It is represented as a non-empty sequence of characters surrounded by single quotes. The name consists of the characters within the single quotes – the single quotes are not included as part of the represented name. The characters within the single quotes may not include non-printable characters (including backspace, tab and newline). However, these characters may be included as part of the name itself through use of an escape sequence. In addition, the single quote character or the backslash character may only be included within the name by using an escape sequence.

   '+'
   'circuits in line'
   'On/Off Switch'
   'Ångström'
   

An escape sequence is a sequence of two text characters starting with a backslash as an escape character, which actually denotes only a single character (except for the newline escape sequence, which represents however many characters is necessary to represent an end of line in a specific implementation). See [KerML, 8.2.2.3] for a complete description of unrestricted names and escape sequences.

In addition to its declaration, the representation for an element may also list other elements owned by the containing element. In the textual notation, such owned elements are shown represented as a body delimited by curly braces {...}, particularly when the owning element is a namespace (see 7.5 ). In the graphical notation, owned elements may be shown in compartments within the symbol representing the owning element, particularly when the owning element is a package, definition or usage (see  7.5 and 7.6.1 ).

A relationship is a kind of element that relates two or more other elements. Some relationships are constrained to have exactly two related elements (i.e., binary relationships) while others may have more. The related elements of relationships are ordered. A relationship may designate certain of its related elements as sources with the rest being targets. In this case, the relationship is said to be directed from the sources to the targets. An undirected relationship simply designates all its related elements to be targets, with no source elements.

A relationship may also be the source or target of other relationships. In particular, a relationship may be annotated by being the target of an annotation relationship (see 7.4 ). In some cases, the annotating element may be owned by the annotated relationship via the annotation relationship, particularly in the case of a documentation comment (see 8.2.2.4.2 ).

Metamodel references:

• Textual notation,  8.2.2.3
• Graphical notation, 8.2.3.3
• Abstract syntax,  8.3.3
• Semantics, none

A dependency is a kind of relationship between any number of client (source) and supplier (target) elements. This implies that a change to a supplier element may result in a change to a client element. Dependencies can be useful for representing relationships between elements in an abstract way.  For example, a dependency can be used to represent that an upper layer of an architecture stack may depend on a lower layer of the stack. A dependency can also be extended to reflect more specialized relationships, such as refinement (e.g., by using user-defined keywords, see 7.27 ).

A dependency is declared textually using the keyword dependency. The client elements of the dependency are then given as a comma-separated list of qualified names following the keyword from, followed by a similar list of the supplier elements after the keyword to. If no short name or name is given for the dependency, then the keyword from may be omitted.

dependency Use 
    from 'Application Layer' to 'Service Layer';

// 'Service Layer' is the client of this dependency, not its name.
dependency 'Service Layer' 
    to 'Data Layer', 'External Interface Layer';

A dependency declaration may also optionally have a body containing any annotating elements owned by the dependency via annotation relationships (see 7.4 ).

dependency 'Service Layer' 
    to 'Data Layer', 'External Interface Layer' {
    /* 'Service Layer' is the client of this dependency, 
     * not its name. */
}

Metamodel references:

• Textual notation,  8.2.2.4
• Graphical notation, 8.2.3.4
• Abstract syntax,  8.3.4
• Semantics, none

An annotating element is an element that is used to provide additional information about other elements. An annotation is a relationship between an annotating element and an annotated element that is being described. An annotating element can annotate multiple annotated elements, and each element can have multiple annotations. 

A comment is one kind of annotating element that is used to provide textual descriptions about other elements. Comments can be members of namespaces and, therefore, can be named. Such member comments may be about the namspace that owns them, or they may be about different elements. Documentation is a distinguished kind of comment used to document the annotated element. Documentation comments always annotate a single element, which is their owning element.

A textual representation is an annotating element whose textual body provides a representation of the annotated element in a specifically named language. This representation may be in the SysML textual notation or it may be in another language. If the named language is machine-parsable, then the body text should be legal input text as defined for that language. In particular, annotating a SysML model element with a textual annotation in a language other than SysML can be used as a semantically "opaque" element specified in the other language.

It is also possible to annotate elements with user-defined metadata, allowing both syntactic and semantic extension of SysML. This capability is described in 7.27 .

The full declaration of a comment begins with the keyword comment, optionally followed by a short name and/or name (see 7.2 ). One or more qualified names of annotated elements for the comment, separated by commas, are then given after the keyword about, indicating that the comment has annotation relationships to each of the identified elements. The body of the comment is written lexically as text between /* and */ delimiters.

item A;
part B;
comment Comment1 about A, B
    /* This is the comment body text. */

If the comment is an owned member of a namespace (see 7.5 ), then the explicit identification of annotated elements can be omitted, in which case the annotated element is implicitly the containing namespace. Further, in this case, if no short name or name is given for the comment, then the comment keyword can also be omitted.

package P {
    comment C /* This is a comment about P. */

    /* This is also a comment about P. */
}

A locale can also be specified for a comment, using the keyword locale followed by the locale string, placed immediately before the comment body (whether or not the comment keyword is used). The locale identifies the language of the body text and, optionally, the region and/or encoding. The format is language[_territory][.codeset][@modifier] (conformant to [ISO15897]).

comment C_US_English locale "en_US"
    /* This is US English comment text */

A documentation comment is notated similarly to a regular comment, but using the keyword doc rather than comment. The documenting element of documentation is always the owning element of the documentation.

part X {
    doc X_Comment
        /* This is a documentation comment about X. */
    doc /* This is more documentation about X. */
}

When a comment is written in the textual notation, the actual body text of the comment is extracted from the lexical comment body according to the rules given in the KerML specification [KerML, 8.2.3.3.2]. The body text of a comment can include markup information (such as HTML), and a tool may graphically display such text as rendered according to the markup. However, marked up "rich text" for a comment is stored in the comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules referenced above.

A textual representation is notated similarly to a regular comment, but with the keyword rep used instead of comment. As for documentation, a textual representation is always owned by its represented element. In particular, if the textual representation is an owned member of a namespace (see  7.5 ), then the represented element is the containing namespace. A textual representation declaration must also specify the language as a literal string following the keyword language. If the textual representation has no short name or name, then the rep keyword can also be omitted.

part def C {
    attribute x: Real;
    assert x_constraint {
        rep inOCL language "ocl" 
        /* self.x > 0.0 */
    }
}
action def setX(c : C, newX : Real) {
    language "alf"
        /* c.x = newX;
         * WriteLine("Set new x");
         */
}

The lexical comment text given for a textual representation is processed as for regular comment text, and it is the result after such processing that is the textual representation body expected to conform to the named language.

Note. Since the lexical form of a comment is used to specify the textual representation body, it is not possible to include comments of a similar form in the body text.

The language name in a textual representation is case insensitive. The name can be of a natural language, but will often be for a machine-parsable language. In particular, there are recognized standard language names.

If the language is  "sysml", then the body of the textual representation must be a legal representation of the represented element in the SysML textual notation. A tool can use such a textual representation to record the original SysML notation text from which an element is parsed. Other standard language names that can be used in a textual representation include "kerml", "ocl", and "alf", in which case the body of the textual representation must be written in the Kernel Modeling Language [KerML], Object Constraint Language [OCL] or the Action Language for fUML [Alf], respectively. (This is the same set of standard language names as in [KerML, 7.2.4.3, 8.3.2.3], with the addition of "sysml".)

However, for any other language than "sysml", the SysML specification does not define how the body text is to be semantically interpreted as part of the model being represented. An element with no other definition than a textual representation in a language other than SysML is essentially a semantically "opaque" element specified in the other language. Nevertheless, a conforming SysML tool may (but is not required to) interpret such an element consistently with the specification of the named language.

Metamodel references:

• Textual notation,  8.2.2.5
• Graphical notation, 8.2.3.5
• Abstract syntax,  8.3.5
• Semantics, none

A namespace is a kind of element that can contain other elements and provide names for them. The elements contained in a namespace are referred to as its member elements. Membership is a kind of relationship that relates a namespace to its members. A membership relationship can specify the name by which its member element is known relative to the containing namespace and whether the element membership is visible outside the namespace or not (see 7.5.2 ).

An element may be owned via its membership in a namespace. When a namespace is deleted, all such owned members will also be deleted. An element may also have a membership in a namespace without being owned by the namespace. In this case, the membership may introduce an alias name for the element relative to the namespace. Note that it is possible for an element to have both owning and non-owning memberships with the same namespace, but it can have at most one owning membership across all namespaces.

An import relationship allows one namespace to import memberships from another namespace (see 7.5.3 ). The member elements from imported memberships become (unowned) members of the importing namespace in addition to being members of the imported namespace. In particular, this allows members of the imported namespace to be referenced in textual notations within the scope of the importing namespace without having to qualify the member names with the name of the imported namespace. An import can also be recursive, which means that, in addition to importing members of the referenced namespace itself, all namespaces that are owned members of the imported package are also recursively imported.

A package is a kind of namespace that is used solely as a container for other elements to organize the model. In addition, a package has the capability to filter imported elements based on certain conditions (see 7.5.4 ), usually defined in terms of the metadata provided by annotations of those elements (see 7.4 and 7.27 ). Only elements that meet all filter conditions actually become imported members of the package. Together, recursive import and filtering provide a general capability for specifying that a package automatically contain a set of elements identified from across a model by their metadata.

In addition to packages, all kinds of SysML definitions and usages are also namespaces (see 7.6 and following subclauses). All rules discussed generically for namespaces in this subclause 7.5 apply generically to packages, definitions and usages (even though the examples in this subclause are given using packages).

In general, an element may have different names in different namespaces, and the same name may identify different elements relative to different namespaces. Therefore, to unambiguously identify an element by name, the element name must be qualified by the namespace relative to which the element name is to be resolved. Such a qualified name is notated by specifying a name to identify the namespace, followed by the symbol ::, followed by the element name. Since the namespace name may also be qualified, a qualified name is most generally a sequence of segment names separated by :: punctuation, of which all but the last must identify namespaces. An unqualified name can be considered the degenerate case of a qualified name with just one element name in its sequence, for which the namespace to be used is implicit.

Note that qualified names do not appear in the abstract syntax. Instead, the abstract syntax representation contains actual references to the identified elements. Name resolution is the process of determining the element that is identified by a qualified name. An unqualified name used within the body of a namespace is resolved in the context of that namespace and, potentially, other namespaces in which the first namespace is lexically nested, taking into account imported (see 7.5.3 ) and inherited (see 7.6 ) memberships. A qualified name with more than one segment is resolved by recursively resolving the name of the qualifying namespace and then resolving the element name in that context. The full name resolution process is specified in [KerML, 8.2.3.5].

A package is declared using the keyword package, with the owned members of the package listed in its body.

package Configurations {
    attribute def ConfigEntry {
        attribute key: String;
        attribute value: String;
    }
    item ConfigData {
        attribute entries[*]: ConfigEntry;
    }
}

In general, declaring an element within the body of a namespace denotes that the element is an owned member of the namespace—that is, that there is an owning membership relationship between the namespace and the member element. The visibility of the membership can be specified by placing one of the keywords public, protected or private before the public element declaration. If the membership is public (the default), then it is visible outside of the namespace. If it is private, then it is not visible. For namespaces other than definitions and usages, protected visibility is equivalent to private. For definitions and usages, protected visibility has a special meaning relating to member inheritance (see  7.6 ).

package P {
    public part def A;
    private attribute def B;
    part a : A; // public by default
}

An alias for an element is a non-owning membership of the element in a namespace, which may or may not be the same namespace that owns the element. An alias name or short name is determined only relative to its membership in the namespace, and can therefore be different than the name or short name defined on the element itself. Note that the same element may be related to a namespace by multiple alias memberships, allowing the element to have multiple, different names relative to that namespace.

An alias is declared using the keyword alias followed by the alias short name and/or name, with a qualified name identifying the element given after the keyword for. An alias declaration may also optionally have a body containing annotating elements for the alias (see 8.2.2.4.1 ). The visibility of the alias membership can be specified as for an owned member.

package P1 {
    item A;
    item B;
    alias <C> CCC for B {
        doc /* Documentation of the alias. */
    }
    private alias D for B;
}

A comment (see 7.4 ), including documentation, declared within a namespace body also becomes an owned member of the namespace. If no annotated elements are specified for the comment (with an about clause), then, by default, the comment is considered to be about the containing namespace.

package P9 {
    item A;
    comment Comment1 about A
        /* This is a comment about item A. */

    comment Comment2
        /* This is a comment about package P9. */

    /* This is also a comment about package P9. */

    doc P9_Doc
         /* This is documentation about package P9. */ 
}

An owned import of a Namespace is denoted using the keyword import followed by a qualified name, optionally suffixed by "::*" and/or "::**".

If the qualified name in an import does not have any suffix, then this specifies a membership import whose imported membership is identified by the qualified name. Such an import results in the identified membership becoming an imported membership of the namespace owning the import. That is, the member element of this membership becomes an imported member of the importing namespace. Note that the imported membership may be an alias membership (see 7.5.2 ), in which case the element is imported with that alias name.

package P2 {
    private import P1::A;
    private import P1::C; // Imported with name "C".
    package Q {
        import C; // "C" is re-imported from P2 into Q.
    }
}

If the qualified name in an import is further suffixed by "::*", then then this specifies a namespace import in which the qualified name identifies the imported namespace. In this case, all visible memberships of the imported namespace of the import become imported memberships of the importing namespace.

package P3 {
    // Memberships A, B and C are all imported from P1.
    private import P1::*;
}

If the declaration of either a membership or namespace import is further suffixed by "::**", then the import is recursive. Such an import is equivalent to importing memberships as described above for either an imported membership or namespace, followed by further recursively importing from each imported member that is itself a namespace, with the following limitations:

1. Recursive import only continues with a namespace that is either the imported element of an original recursive membership import or an owned member of an imported namespace.
2. Memberships inherited via implicit specializations (of any kind) are not imported by recursive imports (see also 7.6.8 on Implicit Specialization).

package P4 {
    item A;
    item B;
    package Q {
        item C;
    }
}
package P5 {
    private import P4::**;
    // The above recursive import is equivalent to all
    // of the following taken together:
    //     private import P4;
    //     private import P4::*;
    //     private import P4::Q::*;
}
package P6 {
    private import P4::*::**;
    // The above recursive import is equivalent to all
    // of the following taken together:
    //     private import P4::*;
    //     private import P4::Q::*;
    // (Note that P4 itself is not imported.)
}

The visibility of an import is always shown explicitly by placing the keyword private, protected, or public before the import declaration. If the import is private (which is the default in the abstract syntax), then the imported memberships become private relative to the importing namespace. A visibility of protected is the same as private, unless the importing namespace is a definition or usage, in which case the imported memberships are also visible in all specializations of the definition or usage (see also 7.6 on inheritance). If the import is public, then all the imported memberships become public for the importing namespace. An import declaration may also optionally have a body containing annotating elements owned by the import (see 8.2.2.4.1 ).

package P7  {
    public import P1::A {
        /* The imported membership is visible outside P7. */
    }

    private import P4::* {
        doc /*  None of the imported memberships are visible 
             * outside of P7. */

}

A package may also contain filter conditions that filter the imports for the package. A filter condition is a Boolean-valued, model-level evaluable expression (see [KerML. 7.4.9]) declared using the keyword filter followed by a Boolean-valued, model-level evaluable expression (see [KerML. 7.4.9]). The filter conditions of a package are evaluated on the member elements of all memberships that are potentially to be imported into the package (see 7.5.3 ). Only those memberships that for which all the filter conditions evaluate to true are actually imported.

Filter conditions can, for example, be used to select which elements to import into a package based on metadata applied to those elements (see also 7.27 on metadata).

package ApprovalMetadata {
    metadata def Approval { 
        attribute approved : Boolean;
        attribute approver : String; 
        attribute level : Natural;
    }
    ...
}

package DesignModel {
    public import ApprovalMetadata::*;
    part System {
         @Approval {
            approved = true;
            approver = "John Smith";
            level = 2;
        }
    }
    ...
}

package UpperLevelApprovals {
    // This package imports all direct or indirect members
    // of the DesignModel package that have been approved
    // at a level greater than 1.
    public import DesignModel::**;
    filter @ApprovalMetadata::Approval and 
           ApprovalMetadata::Approval::approved and
           ApprovalMetadata::Approval::level > 1;
}

Note that a filter condition in a package will filter all imports of that package. That is why full qualification is used for ApprovalMetadata::Approval in the example above, since an imported element of the ApprovalMetadata package would be filtered out by the very filter condition in which the elements are intended to be used. This may be avoided by combining one or more filter conditions with a specific import in a filter import declaration.

A filter import includes one or more filter conditions in the import declaration, listed after the imported membership or namespace specification, each surrounded by square brackets [... ]. For such a filtered import, memberships are imported, from that specific import, if and only if they satisfy all the given filter conditions.

package UpperLevelApprovals {
    // Recursively import all annotation data types and all 
    // features of those types.
    private import ApprovalMetadata::**;

    // The filter condition for this import applies only to
    // elements imported from the DesignModel package.
    public import DesignModel::**[@Approval and approved and level > 1];
}

The SysML package from the Systems Model Library (see  9.2.22 ) contains a complete model of the SysML abstract syntax represented in SysML itself, and it publicly imports the KerML package from the Kernel Library containing the Kernel abstract syntax model (see [KerML, 9.2.17]). When a filter condition is evaluated on an element, abstract syntax metadata for the element can be tested as if the element had an implicit metadata usage (see  7.27 ) defined by the definition from the SysML package corresponding to the abstract syntax metaclass of the element.

package PackageApprovals {
    private import ApprovalMetadata::*;
    private import SysML::*;

    // This imports all part definitions from the DesignModel that have
    // at least one owned part usage and have been marked as approved.
    public import DesignModel::**[@PartDefinition and
                           @PartDefinition::ownedPart != null and
                           @Approval and
                           Approval::approved];
}

Note. Namespaces other than packages cannot have filter conditions (except for their special use in view definitions and usages – see 7.26 ). However, any kind of namespaces may have filtered imports.

A root namespace is a namespace that has no owner. The owned members of a root namespace are known as top-level elements. Any element that is not a root namespace has an owner and, therefore, must be in the ownership tree of a top-level element of some root namespace.

The declaration of a root namespace is implicit and no identification of it is provided in the SysML notation. Instead, the content of a root namespace is given simply by the list of its top-level elements. For the purposes of model interchange (see [KerML, Clause 10]), a single project may contain one or more root namespace, though there is no syntax for defining a project in the SysML syntax.

doc /* This is a model notated in SysML textual notation. */
item def I;
attribute def A;
item i: I;
package P;

While a root namespace has no explicit owner, it is considered to be within the scope of a single global namespace. This global namespace may contain several root namespaces (such as those being managed as a project), and always contains at least all of the KerML and SysML model libraries (see [KerML, Clause 9] and Clause 9 ). Any root namespace within the global namespace may refer to the name of a top-level element of any other root namespace using an unqualified name (since root namespaces are themselves never named).

If an import is owned by a root namespace, then the memberships imported by it are visible to and within all the top-level elements of the root namespace. However, an import owned by a root namespace is required to be private, so none of the imported memberships become globally visible outside of the root namespace. (This rule disallows the "re-export" of the same element from multiple different root namespaces, which would cause ambiguity that could complicate the resolution of unqualified, globally-visible names.)

Metamodel references:

• Textual notation,  8.2.2.6
• Graphical notation, 8.2.3.6
• Abstract syntax,  8.3.6
• Semantics, 8.4.2

Definitions and Usages

The modeling capabilities of SysML facilitate reuse in different contexts. Definition and usage elements provide a consistent foundation for many SysML language constructs to provide this capability, including attributes, occurrences, items, parts, ports, connections, interfaces, allocations, actions, states, calculations, constraints, requirements, concerns, cases, analysis cases, verification cases, use cases, views, viewpoints and renderings. 

In general, a definition element classifies a certain kind of element (e.g., a classification of attributes, parts, actions, etc.). A usage element is a usage of a definition element in a certain context. A usage must always be defined by at least one definition element that corresponds to its usage kind. For example, a part usage is defined by a part definition, and an action usage is defined by an action definition. If no definition is specified explicitly, then the usage is defined implicitly by the most general definition of the appropriate kind from the Systems  Library (see 9.2 ). For example, a part usage is implicitly defined by the most general part definition Part from the model library package Parts.

Features

A definition may have owned usage elements nested in it, referred to as its features. A usage may also have nested usage elements as features. In this case, the context for the nested usages is the containing usage. A simple example is illustrated by a parts tree that is defined by a hierarchy of part usages. A vehicle usage defined by Vehicle could contain part usages for engine, transmission, frontAxle,  and rearAxle. Each part usage has its own (implicit or explicit) part definition.

A feature relates instances of its featuring definition or usage to instances of its definition. For example, a mass feature with definition MassValue, featured by the definition Vehicle, relates each specific instance of Vehicle to the specific MassValue for that vehicle, known as the value of the mass feature of the vehicle.

A usage can also be contained directly in an owning package. In this case, the usage element is considered to be an implicit feature of the most general kernel type Anything. That is, a package-level usage is essentially a generic feature that can be applied in any context, or further specialized in specific contexts (as described under Specialization below).

A usage may have a multiplicity that constrains its cardinality, that is, the allowed number of values it may have for any instance of its featuring definition or usage. The multiplicity is specified as a range, giving the lower and upper bound expressions that are evaluated to determine the lower and upper bounds of the specified range. The bounds must be natural numbers. The lower bound must be finite, but the upper bound may also have the infinite value *.  An upper bound value of * indicates that the range is unbounded, that is, it includes all numbers greater than or equal to the lower bound value. If a lower bound is not given, then the lower bound is taken to be the same as the upper bound, unless the upper bound is *, in which case the lower bound is taken to be 0. For example, a Vehicle definition could include a usage element called wheels with multiplicity 4, meaning each Vehicle has exactly four wheels. A less restrictive constraint, such as a multiplicity of 4..8, means each Vehicle can have 4 to 8 wheels.

A usage may be referential or composite. A referential usage represents a simple reference between a featuring instance and one or more values. A composite usage, on the other hand, indicates that the related instance is integral to the structure of the containing instance. As such, if the containing instance is destroyed, then any instances related to it by composite usages are also destroyed. For example, a Vehicle would have a composite usage of its wheels,  but only a referential usage of the road on which it is driving.

Note. The concept of composition only applies to occurrences that exist over time and can be created and destroyed (see 7.9 ). Attribute usages are always referential and any nested features of attributes definitions and usages are also always referential (see 7.7 ).

Specialization

Definition and usage elements can be specialized using several different kinds of specialization relationships.

A definition is specialized using the subclassification relationship. The specialized definition inherits the features of the more general definition element and can add other features. For example, if Vehicle has a feature called fuel, that is defined by Fuel, and Truck is a specialized kind of Vehicle, then Truck inherits the feature fuel. An inherited feature can be subsetted or redefined as described below. The Truck definition can also add its own features such as cargoSize.

A definition can specialize more than one other definition, in which case the definition inherits the features from each of the definitions it specializes. All inherited features must have names that are distinct from each other and any owned features of the specializing definition. Name conflicts can be resolved by redefining one or more of the otherwise conflicting inherited features (see below).

A usage inherits the features from its definition in the same way that a specialized definition inherits from a more general definition element. For example, if a part usage vehicle is defined by a part definition Vehicle, and Vehicle has a mass defined by MassValue, then vehicle inherits the feature mass. In some cases, a usage may have more than one definition element, in which case the usage inherits the features from each of its definition elements, with the same rules for conflicting names as described above for subclassification. A usage can also add its own features, and subset or redefine its inherited features. This enables each usage to be modified for its context.

A usage can be specialized using the subsetting relationship. A subsetting usage has a subset of the values of the subsetted usage. The subsetting usage may further constrain its definition and multiplicity. For the example above, Truck inherits the feature wheels with multiplicity 4..8 from Vehicle. The part usage truck further inherits wheels with multiplicity 4..8 from Truck. The part usage truck can subset wheels by defining frontLeftWheel, frontRightWheel, rearLeftwheel1, and rearRightWheel1, each with multiplicity 1..1, together giving the minimum total multiplicity of 4. The truck usage can then define additional subsets of wheels, such as rearLeftwheel2, and rearRightwheel2, with multiplicity 0..1, indicating they are optional.

Redefinition is a kind of subsetting. While, in general, a subsetting usage is an additional feature to the subsetted usage, a redefining usage replaces the redefined usage in the context of redefining usage. For the example above, Vehicle contains a feature called fuel that is defined by Fuel. Truck inherits fuel from Vehicle. The part usage truck would then normally inherit fuel as defined by Fuel from Truck. However, truck can instead redefine fuel to restrict its definition to DieselFuel, a subclassification of Fuel. In this case, the new redefining feature replaces the fuel feature that would otherwise be inherited, meaning that the fuel of the truck part must be defined by DieselFuel.

A usage, particularly one with nested usages, can be reused by subsetting it. For example, subsetting the part usage vehicle is analogous to specializing the part definition Vehicle. Suppose vehicle1 is a part usage that subsets vehicle, with the parts-tree decomposition described above. This enables vehicle1 to inherit the features and structure of vehicle. The part usage vehicle1 can be further specialized by adding other part usages to it, such as a body and chassis, and it can redefine parts from vehicle as needed. For example, vehicle1 may redefine engine to be a 4-cylinder engine. The original part vehicle remains unchanged, but vehicle1 is a unique design configuration that specializes vehicle. Other part usages, such as vehicle2, could be created in a similar way to represent other design configurations.

Note. If the part definition Vehicle is modified, the modification will propagate down through the specializations described above. However, it is expected that if Vehicle is baselined in a configuration management tool, then a change to Vehicle is a new revision, and it is up to the modelers to determine whether to retain the previous version of Vehicle or move to the next revision.

Variability

Variation and variant are used to model variability typically associated with a family of design configurations. A variation (sometimes referred to as a variation point) identifies an element in a model that can vary from one design configuration to another. One example of a variation is an engine in a vehicle.  For each variation, there are design choices called variants. For this example, where the engine feature is designated as a point of variation, the design choices are a 4-cylinder engine variant or a 6-cylinder engine variant.

Variation can apply to any kind of definition or usage in the model (except for enumeration, see 7.8 ). The variation element then specifies all possible variants (i.e., choices) for that variation point. For example, the specified variants for the engine variation are the 4-cylinder engine and the 6-cylinder engine.

Variants are usage elements. If the containing variation is a definition, then each of its variants is implicitly defined by the variation definition. If the containing variation is a usage, then each of its variants implicitly subsets the variation usage. For example, the 4-cylinder engine and the 6-cylinder engine are subsets of all possible engines.

Variations can be nested within other variations, to any level of nesting. For example, the 6-cylinder engine variant may in turn contain cylinders with a variation for bore diameter that includes variants for small-bore diameter and large-bore diameter. Alternatively, the bore diameter variation could be applied more generally to the cylinder of engine, enabling both the 4-cylinder engine and the 6-cylinder engine to have this variation point.

A model with variability can be quite complex since the variation can extend to many other aspects of the model including its structure, behavior, requirements, analysis, and verification. Also, the selection of a particular variant often impacts many other design choices that include other parts, connections, actions, states, and attributes.  Constraints can be used to constrain the available choices for a given variant. For example, the choice of a 6-cylinder engine may constrain the choice of transmission to be an automatic transmission, whereas the choice of a 4-cylinder engine may allow for both an automatic transmission or a manual transmission.

Variations and variants are used to construct a model that is sometimes referred to as a superset model, which includes the variants to configure all possible design configurations. A particular configuration is selected by selecting a variant for each variation. SysML provides validation rules that can evaluate whether a particular configuration is a valid configuration based on the choices and constraints provided in the superset model.  Variability modeling in SysML can augment other external variability modeling applications, which provide robust capabilities for managing variability across multiple kinds of models such as CAD, CAE, and analysis models, and auto-generating the variant design configurations based on the selections.

Note. The approach to variability modeling in SysML is intended to align with industry standards such as ISO/IEC 26580:2021 Software and systems engineering — Methods and tools for the feature-based approach to software and systems product line engineering.

Graphical Compartments

The graphical notation for a definition or usage may include one or more compartments, which show member elements (if any) using textual or graphical notation. In the graphical symbols in all Representative Notation tables in Clause 7 , the term compartment stack is a placeholder for any valid compartment for the model element.

There is a basic common notation for all kinds of definitions, as described here in subclause 7.6 , with additional special notations for certain kinds of definitions described in the later subclauses specifically related to those kinds of definitions. As a kind of Namespace (see 7.5 ), the representation of a definition includes a declaration and a body.

A definition is declared using a keyword specific to the kind of definition (e.g., item, part, action, etc.) followed by the keyword def. One or more owned subclassifications may also optionally be included in the declaration of a definition by giving a comma-separated list of qualified names of the general definitions after the keyword specializes (or the symbol :>). A definition is specified as abstract by placing the keyword abstract before its kind keyword.

abstract part def Vehicle;
part def Automobile specializes Vehicle;
part def Truck :> Vehicle;

A definition that is not abstract is called a concrete definition. Declaring a definition to be abstract means that all instances of the definition must also be instances of at least one concrete definition or usage that directly or indirectly specializes the abstract definition.

The body of a definition is specified generically as for any namespace. In the textual notation, this is done by listing the members and imports between curly braces {... } (see 7.5 ), or alternatively by a semicolon ; if the definition has no members or imports. Usages declared within the body of a definition are owned usages that specify features of the Definition.

item def Super {
    private package N {
        item def Sub specializes Super;
    }
   item f : N::Sub;
}

There is a basic common notation for all kinds of usages, as described here in subclause 7.6 , with additional special notations for certain kinds of usage described in the later subclauses specifically related to those kinds of usages. As a kind of namespace (see 7.5 ), the representation of a usage includes a declaration and a body.

A usage is declared using a keyword specific to the kind of usage (e.g., item, part, action, etc.). One or more owned specializations may also optionally be included in the declaration of a usage. There are three kinds of specializations relevant to usages:

1. Feature typings specify the definitions of a usage (also known as its types). Textually, they are declared by giving a comma-separated list of the qualified names of the definition elements after the keyword defined by (or the symbol :). The definitions given must be consistent with the kind of usage being defined.
2. Subsettings specify other usages subsetted by the owning usage. Textually, they are declared by giving a comma-separated list of the qualified names of the subsetted usages after the keyword subsets (or the symbol :>).
3. Redefinitions specify other usages redefined by the owning usage. Textually, they are declared by giving a comma-separated list of the qualified names of the redefined usages after the keyword redefines (or the symbol :>>). (Note that redefinition is a kind of subsetting, so the owned redefinitions of a usage will be a subset of the owned subsettings in the abstract syntax.)

item x : A, B :> f :>> g;

// Equivalent declaration:
item x defined by A defined by B subsets f redefines g;

The multiplicity of a usage can be given in square brackets [... ] after the name part of the declaration of a usage (if it is named) or after one of the owned specialization clauses in the declaration (but, in all cases, only one multiplicity may be specified). (This allows for a notation style consistent with previous modeling languages, in which the multiplicity is always placed after the declared type.)

A multiplicity range is written in the form [lowerBound..upperBound], where each of lowerBound and upperBound is either a literal or the identification of a usage. Literals can be used to specify a multiplicity range with fixed lower and/or upper bounds. The values of the bounds of a multiplicity range must be natural numbers. If only a single bound is given, then the value of that bound is used as both the lower and upper bound of the range, unless the result is the infinite value *, in which case the lower bound is taken to be 0. If two bounds are given, and the value of the first bound is *, then the meaning of the multiplicity range is not defined.

item def Person {
    ref item parent[2] : Person;
    ref item mother : Person[1..1] subsets parent;
    attribute numberOfChildren : Natural;
    ref item children[0..numberOfChildren] : Person;
}
item def ChildlessPerson specializes Person {
    ref item redefines children[0];
}

A multiplicity may be optionally followed by one or both of the following keywords (in either order), or they can be used without giving an explicit muiltiplicity, at any place in the declaration a multiplicity would be allowed.

• nonunique – If a usage is non-unique, then the same value may appear more than once as a value of the usage. The default is that the usage is unique, meaning that no two values of the usage may be the same.
• ordered – If a usage is ordered, then the values of the usage can be placed in order, indexed from 1 to the number of values. The default is that the feature is unordered.

If a multiplicity is not declared for a usage, then the usage inherits the multiplicity constraints of any other usages it subsets or redefines. If no tighter constraint is inherited, the effective default is the most general multiplicity [0..*]. However, a tighter default of [1..1] is implicitly declared for the usage if all of the following conditions hold:

1. The usage is an attribute usage, an item usage (including a part usage, except if it is a connection usage), or a port usage.
2. The usage is owned by a definition or another usage (not a package).
3. The usage does not have any explicit owned subsettings or owned redefinitions.

There are a number of additional properties of a usage that can be flagged by adding specific keywords to its declaration. If present these are always specified in the following order, before the kind keyword in the usage declaration.

1. in, out, inout – Specifies a directed usage with the indicated direction, which determines what things are allowed to change its values relative to its featuring instance.
   • in – Things "outside" the featuring instance. These usages identify things input to an instance.
   • out – The featuring instance itself or things "inside" it. These usages identify things output by an instance.
   • inout – Both things "outside" and "inside" the featuring instance. These usages identify things that are both input to and output by an instance.
2. derived – Specifies that the usage is derived. Such a feature is typically expected to have a bound value expression that completely determines its value at all times (see also 7.13.3  on binding a usage to a value).
3. abstract – Specifies that the usage is abstract. A usage that is not abstract is called a concrete usage. Similarly to an abstract definition (see 7.6.2 ), declaring a usage to be abstract means that any value of the usage must also be a value of some concrete usage that directly or indirectly specializes (subsets or redefines) the abstract usage.
4. constant – Specifies that the usage is constant. Values of a constant usage are the same during the entire existence of the featuring instance. Note that this only applies if the featuring instance is an occurrence and the usage is such that its values would otherwise be allowed to vary over time if it was not constrained to be constant (see also  7.9.2 on occurrences and usages with time-varying values).
5. ref – Specifies that the usage is referential. A usage that is not referential is composite. Values of a composite usage, for each featuring instance, cannot exist after the featuring instance ceases to exist. A composite usage must be featured by an occurrence (such as an item, part or action; see  7.9 and following). This only applies to values at the time the instance goes out of existence, not to other things that may have been values of the usage before that, but are not any longer. Values of a composite usage cannot be values of another composite usage unless it is on the same featuring instance. (Note also that a directed usage is always referential, whether or not the keyword ref is also given explicitly in its declaration.)

abstract part def Container {
    abstract ref item content;
}
part def Tank :> Container {
    in item fuelFlow : Fuel;
    ref item fuel : Fuel :>> content;
}

(See also the discussion of end features in 7.13.2 .)

The body of a usage is specified generically as for any namespace. In the textual notation, this is done by listing the members and imports between curly braces {... } (see 7.5 ), or alternatively by a semicolon ; if it has no members or imports. Usages declared within the body of another Usage are owned (nested) usages that specify features of the owning usage.

part vehicle : Vehicle {
    part wheelAssembly[2] {
        part axle : Axle;
        part wheel : Wheel;
    }
}

A reference usage is a usage that is declared without any kind keyword. Unlike other kinds of usages, the definitions (types) of a reference usage are not restricted to be of a particular kind. The declaration of a reference usage may, but is not required, to include the ref keyword. However, a reference usage is always, by definition, referential. A reference usage is otherwise declared like any other usage, as given above.

abstract part def Container {
    abstract ref content : Base::Anything;
}
part def OrderedContainer {
    // By default, the following is a reference usage.
    orderedContent ordered :>> content;
}

If a name and/or short name are declared for an element, these are used in the name resolution process to identify the element (as discussed in  7.6.1 ). However, if neither a name or a short name are given in the declaration of a usage with an owned redefinition, then its effective name and short name are implicitly determined by the name and short name of the redefining usage of its first owned redefinition (which may itself be an implicit name, if the redefined usage is itself a redefining usage). This is useful when redefining a usage in order to constrain it, while maintaining the same naming as for the original usage.

part def Engine {
    part cylinders : Cylinder[2..*];
}
part def FourCylinderEngine :> Engine {
    // This redefines Engine::cylinders with a
    // new usage, restricting the multiplicity 
    // to 4. It's declared name is empty,
    // but its effective name is "cylinders".
    part redefines cylinders[4];
}
part def SixCylinderEngine :> Engine {
    part redefines cylinders[6];
}

Certain other kinds of usages (such as perform action usages) specify an alternate effective name rule, as described in the subclauses relevant to those usages (e.g.,  7.17.6 describes the rule for perform action usages).

A feature chain is a textual notation specified as a sequence of two or more qualified names separated by dot (.) symbols. Each qualified name in a feature chain must resolve to a Usage (or, more generally, a KerML Feature). The first qualified name in a feature chain is resolved in the local namespace as usual (see 7.6.1 ). Subsequent qualified names are then be resolved using the previously resolved usage (feature) as the context namespace, but considering only public memberships.

A feature chain is similar to a qualified name but, unlike a qualified name, the path of usages (features) in the chain is recorded in the abstract syntax, not just the reference to the final usages. This means that different paths to the same usage can be distinguished in the abstract syntax representation of a model. Feature chains can be used to specify the target for most kinds of relationships involving usages, including subsetting and redefinition. However, their use is particularly important when specifying the related features of a connection usage that are more deeply nested than the connection usage itself (see 7.13 ). (See also [KerML, 7.3.4.6].)

item uncles subsets parents.siblings;
item cousins redefines parents.siblings.children;
connect vehicle.wheelAssembly.wheels to vehicle.road;

In general, when a textual notation is described as including the identification of a usage, this can be done by using either a qualified name or a feature chain.

A definition or usage is specified as a variation by placing the keyword variation before its kind keyword. A variation is always abstract, so the abstract keyword is not used on a variation.

All usages declared within the body of a variation definition or usage are declared as variant usages by placing the keyword variant at the beginning of their declarations. Variant usages may only be declared within a variation. The kind of a variant usage must be consistent with the kind of its owning variation.

variation part def TransmissionChoices :> Transmission {
    variant part manual : ManualTransmission;
    variant part automatic : AutomaticTransmission;
}

A non-variant usage can also be declared to act as a variant of a variation by not including a kind keyword in the variant declaration and, instead, following the variant keyword with the identification of a separately declared usage. Such a variant declaration may also optionally further constrain the variant usage by including a multiplicity and/or further specializations.

// These are non-variant usages.
part smallEngine : FourCylinderEngine;
part bigEngine : SixCylinderEngine;

part def Vehicle {
    variation part engine : Engine {
        // These are variant usages within the variation part "engine", 
        // based on the referenced non-variant usages. 
        variant smallEngine;
        variant bigEngine;
    }
}

The meaning or semantics of a definition is given by what things it classifies relative to the system being modeled. Specific kinds of definitions are already restricted to classifying specific kinds of things. E.g., an attribute definition classifies attributive values, a part definition classifies systems and parts of systems, etc.

The Systems Model Library (see 9.2 ), which is based on the KerML Kernel Semantic Library (see [KerML, 9.2]) is a set of ontological SysML models that define the basic kinds of things relevant for systems modeling. The semantics of definition elements in SysML is given by requiring that each such element (directly or indirectly) specialize the corresponding base definition from the Systems Model Library (or base classifier from the Kernel Semantic Library) corresponding to its kind.

At the highest level, every definition element must directly or indirectly specialize the most general classifier Anything from the Base model in the Kernel Semantic Library (see [KerML, 9.2.2]). Specific kinds of definition then have more specific requirements for what more specific base definition they must specialize. For example, an attribute definition must specialize the base attribute definition AttributeValue from the Attributes model in the Systems Model Library, while a part definition must specialize the base part definition Part from the Parts model.

The Systems Model Library also includes a parallel hierarchy of base usages (or base features in the Kernel Semantic Library). So, every usage element must directly or indirectly specialize (subset) the most general feature things from the from the Base model in the Kernel Semantic Library. And specific kinds of usage then also have more specific requirements for what more specific base usage they must specialize. For example, an attribute usage must subset the base attribute usage attributeValues from the Attributes model in the Systems Model Library, while a part usage must subset the base part usage parts from the Parts model. In general, each base usage is defined by the corresponding base definition. E.g., the base usage parts is defined by the base definition Part, so that every part usage is ultimately a direct or indirect usage of Part.

These and other semantic constraints are fully described in 8.4 . However, it is not generally necessary for a modeler to explicitly satisfy these constraints when constructing a model. Rather, the violation of a semantic constraint implies the need for a specific relationship, which may then be added to the model automatically by tooling (see also [KerML, 8.4.2]). In particular, if a definition or usage, as explicitly declared, does not directly or indirectly specialize the required base definition or usage, then the declaration is considered to include an implicit subclassification or subsetting of the appropriate base definition or usage.

attribute def A;     // Implicitly subclassifies Attributes::AttributeValue.
part def P {         // Implicitly subclassifies Parts::Part.
    ref x;           // Implicitly subsets Base::things.
    attribute a : A; // Implicitly subsets Attributes::attributeValues.
    part p;          // Implicitly subsets Parts::parts.
    part q :> p;     // No implicit specialization.
}
part def Q :> P;     // No implicit specialization.

Metamodel references:

• Textual notation,  8.2.2.7
• Graphical notation, 8.2.3.7
• Abstract syntax,  8.3.7
• Semantics, 8.4.3

An attribute definition defines a set of data values, such as numbers, quantitative values with units, qualitative values such as text strings, or data structures of such values. An attribute usage is a usage of an attribute definition. An attribute usage is always referential and any nested features of an attribute definition or usage must also be referential (see also 7.6 on referential and composite usages).

The data values of an attribute usage are constrained to be in the range specified by its definition. The range of data values for an attribute definition can be further restricted using constraints (see 7.20 ). An enumeration definition is a specialized kind of attribute definition that further restricts the values of the data type to a discrete set of data values (see 7.8 ).

Attribute usages can be defined by KerML data types as well as SysML attribute definitions. This allows them to be typed by primitive data types from the Kernel Data Type Library (see [KerML, 9.3]), such as String, Boolean, and numeric types including Integer, Rational, Real and Complex. The Kernel Data Type Library also includes basic structured data types for collections.

Attribute usages representing quantities with units are defined using the SysML Quantities and Units Domain Library or extensions of the elements in this library (see 9.8 ). The library provides base attribute definitions for scalar, vector and tensor quantity values, along with other models that specify the full set of international standard quantity kinds and units. Fundamental to this approach is the principle that only the kind of unit (e.g., MassUnit, LengthUnit, TimeUnit, etc.) is associated with an attribute definition, while a specific unit (e.g., kg, m, s, etc.) is only given with an actual quantity value. This means that an attribute usage for a quantity value is independent of the specific units used, allowing for automatic conversion and interoperability between different units of the same kind (e.g., kilograms and pounds mass, meters and feet, etc.).

The values of an attribute usage are data values, whether primitive values like integers or structured values with nested attributes, that do not themselves change over time. However, the owner of an attribute usage may be an occurrence definition or usage (or a specialized kind of occurrence, such as an item, part or action). In this case, the value of the attribute usage may vary over the lifetime of its owning occurrence, in the sense that it can have different values at different points in time, reflecting the changing condition of the occurrence over time. (See also the discussion in 7.9 .)

An attribute definition is declared as described in 7.6.2 , using the kind keyword attribute. An attribute definition may only specialize other attribute definitions (including enumeration definitions) or KerML data types (see [KerML, 7.4.2]). An attribute usage may be declared as described in 7.6.3 , using the kind keyword attribute. An attribute usage may only be defined by attribute definitions or KerML data types. (See also 7.8 on enumeration definitions and enumeration usages.

An attribute usage is always referential, whether or not the ref keyword (see 7.6.3 ) is used explicitly in its declaration. The default multiplicity of an attribute usage is [1..1], under the conditions described in 7.6.3 . In general, any kind of usage may be declared in the body of an attribute definition or attribute usage, but all such usages shall be referential. (There are further restrictions on what can be nested in an enumeration definition – see 7.8 .)

attribute def SensorRecord {
    ref part sensor : Sensor;    
    attribute reading : Real;
}

The base attribute definition is AttributeValue from the Attributes library model (see 9.2.2 ), which is simply an alias for the data type DataValue from the KerML Base library model (see [KerML, 9.2.2]). The base attribute usage is attributeValues from the Attributes library model, which is simply an alias for the feature dataValues from the KerML Base library model.

Metamodel references:

• Textual notation,  8.2.2.8
• Graphical notation, 8.2.3.8
• Abstract syntax,  8.3.8
• Semantics, 8.4.4

An enumeration definition is a kind of attribute definition (see 7.7 ) whose instances are limited to specific set of enumerated values. An enumeration usage is an attribute usage that is required to have a single definition that is an enumeration definition.

An enumeration usage is restricted to only the set of enumerated values specified in its definition. Since an enumeration definition is a kind of attribute definition, it can also be used to define a regular attribute usage. Even if the attribute usage is not syntactically an enumeration usage, it is still semantically restricted to take on only the values allowed by its enumeration definition.

An enumeration definition can specialize an attribute definition that is not itself an enumeration definition. In this case, the enumerated values of the enumeration definition will be a subset of the attribute values of the specialized attribute definition. Which enumerated values correspond to which attribute values may be specified by binding the enumerated values to expressions that evaluate to the desired values of the specialized attributed definition (see also 7.13 on binding usages to values). In this case, the results of all the expressions must be distinct (typically they will just be literals).

For example, an enumeration definition DiameterChoices may specialize the attribute definition LengthValue. DiameterChoices may include literals that are equal to 60 mm, 80 mm, and 100 mm. An attribute usage called cylinderDiameter can be defined by DiameterChoices, and its value can equal one of the three enumerated values.

An enumeration definition may not contain anything other than the declaration of its enumerated values. However, if the enumeration definition specializes an attribute definition with nested usages, then those nested usages will be inherited by the enumeration definition, and they may be bound to specific values within each enumerated value of the enumeration definition.

An enumeration definition may not specialize another enumeration definition. This is because the semantics of specialization require that the set of instances classified by a definition be a subset of the instances of classified by any definition it specializes. The enumerated values defined in an enumeration definition, however, would add to the set of enumerated values allowed by any enumeration definition it specialized, which is inconsistent with the semantics of specialization.

An enumeration definition is declared as described in 7.6.2 , using the kind keyword enum, with the additional restrictions described below. As a kind of attribute definition, an enumeration definition may generally subclassify other attribute definitions or KerML data types. However, an enumeration definition must not subclassify another enumeration definition. An enumeration usage is declared as described in 7.6.3 , using the kind keyword enum.

Any owned members declared in the body of an enumeration definition must be enumeration usages, which are the enumerated values of the enumeration definition. An enumeration definition is always considered to be a variation and its enumerated values are its variants. The keywords abstract and variation may not be used with an enumeration definition. The declaration of an enumeration usage as an enumerated value of an enumeration definition may not include the keyword variant nor any of the other property keywords given in 7.6.3 (i.e, any direction keywords, abstract, derived, etc.).

Since the body of an enumeration definition may only declare enumeration usages, the declaration of an enumerated value may omit the enum keyword. An enumerated usage declared as an enumerated value is considered to be implicitly defined by its owning enumeration definition and, therefore, may not have any explicitly declared definition other than that enumeration definition (and need not have any explicitly declared definition at all).

enum def ConditionColor { red; green; yellow; }
attribute def ConditionLevel {
    attribute color : ConditionColor;
}
enum def RiskLevel :> ConditionLevel {
    enum low { :>> color = ConditionColor::green; }
    enum medium { :>> color = ConditionColor::yellow; }
    enum high { :>> color = ConditionColor::red; }
}

There are no special restrictions on the declaration of an enumeration usage outside the body of an enumeration definition, other than as for an attribute usage in general (see 9.2.2 ), except that such an enumeration usage must be explicitly defined by a single enumeration definition. As a kind of attribute usage, an enumeration usage is always referential, whether or not ref is included in its declaration, and all the nested usages of an enumeration usage must also be referential.

enum assessedRisk : RiskLevel {
    // The following feature is added for this usage.
    // It is legal, since all attribute usages are
    // referential.
    attribute assessment : String;
}

Metamodel references:

• Textual notation,  8.2.2.9
• Graphical notation, 8.2.3.9
• Abstract syntax,  8.3.9
• Semantics, 8.4.5

Occurrences

An occurrence definition is a definition of a class of occurrences that have an extent in time and may have spatial extent. An occurrence usage is a usage of an occurrence definition.

The extent of an occurrence in time is known as its lifetime, which covers the period in time from the occurrence's creation to its destruction. An occurrence maintains its identity over its lifetime, while the values of its features may change over time. The lifetime of an occurrence begins when the identity of the occurrence is established, and the the lifetime ends when the occurrence loses its identity. For example, the lifetime of a car could begin when it leaves the production-line, or when a vehicle identification number is assigned to the car. Similarly, the lifetime of a car could end when the car is disassembled or demolished.

The performance of a behavior is also an occurrence that takes place over time. The lifetime of a behavior performance begins at the start of the performance and ends when the performance is completed. Structural and behavioral occurrences are often related. For example, a machine on an automobile assembly line, during its lifetime, will repeatedly perform a behavioral task, each performance of which has its own respective lifetime, which then affects the construction of some car being assembled on the line.

If an occurrence definition or usage has nested composite features, then those features must also be usages of occurrence definitions (including the various specialized kinds of occurrences, such as parts, items and actions). If an occurrence has values for any composite features at the end of its lifetime, then the lifetime of those composite values must also end. However, if a composite suboccurrence is removed from its containing occurrence before the end of the lifetime of the containing occurrence, then the former suboccurrence can continue to exist. For example, if a wheel is attached to a car when the car is destroyed, then the wheel is also destroyed. However, if the wheel is removed before the car is destroyed, then the wheel can continue to exist even after the car is destroyed. Values of a composite feature cannot be values of another composite feature except on the same containing occurrence. (See also 7.6 on referential and composite usages.)

Time Slices and Snapshots

The lifetime of an occurrence can be partitioned into time slices which correspond to some duration of time.  These time slices represent periods or phases of a lifetime, such as the deployment or operational phase. Time slices can be further partitioned into other time slices. For example, the lifetime of a car might be divided into time slices corresponding to its assembly, being in inventory before being sold, and then sequential periods of ownership with different owners.

A time slice with zero duration is a snapshot. Start, end and intermediate snapshots can be defined for any time slice to represent particular instants of time in an occurrence's lifetime. For example, the start snapshot of each ownership time slice of a car corresponds to the sale of the car to a new owner, which happens at the same time as the end snapshot of the previous ownership (or inventory) time slice.

Individuals

Any kind of occurrence definition can be restricted to define a class that represents an individual, that is, a single real or perceived object with a unique identity. For example, consider the part definition Car modeling the class of all cars (parts are kinds of items which are kinds of occurrences, see 7.11 ). An individual car called Car1 with a unique vehicle identification number can then be modeled as an individual part definition that is a subclassification of the general part definition Car. As such, Car1 inherits all the features of Car (such as its parts engine, transmission, chassis, wheels, etc.), but has individual values for each of those features (individual engine, individual transmission, individual chassis, four individual wheels, etc.), each of which is itself a uniquely identifiable subclassification of a more general part definition (Engine, Transmission, Chassis, Wheel, etc.).

An occurrence usage can also be restricted to be the usage of a single individual. In this case, exactly one of the definitions of the occurrence usage must be an occurrence definition for that individual. Such an individual usage can be used to model a role that an individual plays for some period of time. For example, the individual part definition Car1 can be used in different contexts, such as the usage of Car1 when it is in for service and the usage of Car1 when it is used for normal operations. Let car1InService be the usage of Car1 when it is in for service to have its tires rotated. For this usage, car1InService has four wheels that play different roles, including front-left, front-right, rear-left, and rear-right. The four wheels of Car1 are individual Wheel usages defined by the individual definitions Wheel1, Wheel2, Wheel3, and Wheel4. Each  of these individual definitions is a subclassification of Wheel. When car1InService enters the shop, the front-left wheel individual usage is initially defined by the individual definition Wheel1, but after the tires are rotated, the front-left wheel is defined by the individual definition Wheel2.

The lifetime of an individual and any of its time slices can be actual or projected. For example, the individual car Car1 may be purchased as a used car. Car1 has had an actual lifetime up to that time. A mechanic may perform diagnostics and obtain some measurements, and may estimate the remaining life of the car or its parts based on the measurements. For example, the mechanic may estimate the remaining lifetime of the tires, based on the tread measurements and the estimated tire wear rate.

At a given point in time, the condition of an individual (sometimes called its "state", which should not be confused with a behavioral state usage, as described in 7.18 ) can be specified by the values of its attributes. As an example, the condition of car1inOperation at different points in time can be specified in terms of its acceleration, velocity, and position. In addition, its finite (i.e., discrete) state (in the sense that can be modeled with state definitions and usages, see 7.18 ) can be specified at different points in time as off or on, and any nested state such as forward or reverse. The condition of the car can continue to change over its lifetime, and can be specified as a function of discrete and/or continuous time.

Events

An event is a reference from one occurrence to another occurrence that represents some relevant happening during the lifetime of the first occurrence. Such an event model makes no commitment as to how the event actually happens. Different specializations of the containing occurrence may realize the modeled event in different ways.

In particular, occurrences may collaborate by transferring information between each other via messages (see 7.16 ). The sending of such a message is an event in the lifetime of the sending occurrence, while the receipt of such a message is an event in the lifetime of the receiving occurrence. These events can possibly be realized as the performance of a send action and corresponding accept action, respectively, with the message being the resulting transfer between them (see 7.17 ). However, it could also be realized as the start and end of an explicitly modeled flow (see 7.16 on flows and messages).

An occurrence definition or usage (that is not of a more specialized kind) can be declared as described in 7.6.2 and 7.6.3 , using the kind keyword occurrence. An occurrence usage may only be defined by occurrence definitions (of any kind) or KerML classes (see [KerML, 7.4.3]).

occurrence def Flight {
     ref part aircraft : Aircraft; 
}

Unlike the features of attribute definitions and usages (see 7.7 ), the features of an occurrence definition or usage may have values that vary over the lifetime of a featuring occurrence. Such variability may be, for example, the result of the binding of a feature to another feature with a varying value (see 7.13.3 ), a flow of values into or out of a feature (see 7.16 ), or an explicit assignment of values to a feature (see 8.2.2.17.5 ). However, the following kinds of features do not vary over time in this way, and, instead, have values relative to the entire duration of the featuring occurrence:

1. Time slices and snapshots, because they represent specific portions of the duration of their featuring occurrences (see 7.9.3 ).
2. Bindings, because they reflect relationships that can hold across time (see 7.13.3 and 7.13.4 ).
3. Successions, because they determine ordering of occurrences across time (see 7.13.5 ).
4. Composite subactions, because their values and ordering across time are determined by succession relationships and other control constructs (see  7.17 on actions and  7.18 on states).

action def ChangeAircraft {
    in flight : Flight;
    in newAircraft : Aircraft;
    // This assignment changes the aircraft for the given flight.
    assign flight.aircraft := newAircraft;
}

A feature that would otherwise be allowed to vary in time may be declared to nevertheless have a constant value using the constant keyword (see 7.6.3 ). Such a feature must have the same value over the entire duration of a featuring occurrence.

occurrence def ApprovedFlight :> Flight {
    // This redefines the aircraft feature so it is constant for
    // an entire ApprovedFlight.
    constant ref part approvedAircraft redefines aircraft;
}

The base definition for occurence definitions is the class Occurrence from the Occurrences model in the Kernel Semantic Library (see [KerML, 9.2.4]). The base usage for occurrence usages is the feature occurrences from the Occurrences model.

An occurrence usage (of any kind) can be declared as a time slice or a snapshot using the keyword timeslice or snapshot, respectively, placed immediately before the kind keyword of the declaration (after any of the other usage property keywords described in 7.6.3 ). Alternatively, timeslice or snapshot may be used in place of the kind keyword, in which case the declaration is equivalent to timeslice occurrence or snapshot occurrence (that is, an occurrence usage not of a more specialized kind, but declared as a time slice or snapshot, respectively).

A time slice or snapshot usage must be declared in the body of an occurrence definition or usage (of any kind). If it is declared in the body of an occurrence definition, then it represents a portion of the instances of the containing occurrence definition. If it is declared in the body of another occurrence usage, then it represents a portion of the instances of the definition(s) of that containing usage. Note that it is allowable to declare a time slice or snapshot usage within a time slice usage. However, it is not generally useful to declare a time slice or snapshot usage within a snapshot usage, since a snapshot is, by definition, without duration.

occurrence def Flight {
    ref part aircraft : Aircraft;
    // The following are time slices of Flight.
    timeslice preflight;
    timeslice inflight;
    timeslice postflight;
}

part aircraft : Aircraft {
    // The following are snapshots of the part aircraft.
    snapshot part aircraftTakeOff;
    snapshot part aircraftLanding;
}

An occurrence definition (of any kind) can be declared as an individual definition using the keyword individual, placed immediately before the kind keyword of the declaration. Alternatively, individual may be used in place of the kind keyword, in which case the declaration is equivalent to individual occurrence (that is, an occurrence usage not of a more specialized kind, but representing an individual).

individual def Flight_248 :> Flight;
individual part def TestPlane_1 :> Aircraft;

An occurrence usage (of any kind) is considered to be an individual usage if it has a definition that is an individual definition. An occurrence usage must not have more than one definition that is an individual definition. An occurrence usage may also be explicitly declared to be an individual usage using the keyword individual, placed after any of the other usage property keywords described in 7.6.3 , but before a timeslice or snapshot keyword (if any). In this case, the occurrence usage must have exactly one definition that is an individual definition. If the declaration of an occurrence usage includes the the keyword individual (and, possibly, timeslice or snapshot), but no kind keyword, then this is equivalent to having included the occurrence keyword (that is, an occurrence isage not of a more specialized kind, but representing an individual, and, possibly, a time slice or snapshot).

individual flightRecord : Flight_248 {
    individual part redefines aircraft : TestPlane_1;
    individual timeslice redefines preflight;
    individual timeslice redefines inflight;
    individual timeslice redefines postflight;
}

An event occurrence usage is declared like an occurrence usage, as described in 7.9.2 , 7.9.3 , and 7.9.4 , but using the kind keyword event occurrence instead of just occurrence. It is related to another occurrence usage, representing the occurring event, by a reference subsetting relationship, which is a special kind of subsetting relationship specified using the keyword references or the symbol ::>. Or, if the event occurrence usage has no such reference subsetting, then the referenced event occurrence is the event occurrence usage itself.

part client {
    event occurrence request[1] references subscriptionMessage.source;
    event occurrence delivery[*] ::> publicationMessage.target;
}

An event occurrence usage may also be declared using just the keyword event instead of event occurrence. In this case, the declaration does not include either a name or a short name. Instead, the referenced event occurrence of the event occurrence usage is identified by giving a qualified name or feature chain immediately after the event keyword.

part client {
    event subscriptionMessage.source[1];
    event publicationMessage.target[*];
}

The ref keyword may be used in the declaration of an event occurrence usage, but an event occurrence usage is always referential, whether or not ref is included in its declaration.

Metamodel references:

• Textual notation,  8.2.2.10
• Graphical notation, 8.2.3.10
• Abstract syntax,  8.3.10
• Semantics, 8.4.6

An item definition is a kind of occurrence definition (see 7.9 ) that defines a class of identifiable objects that may be acted on over time, but which do not necessarily perform actions themselves. An item usage is a usage of one or more item definitions.

Item usages can be used to represent inputs and outputs to actions such as water, fuel, electrical signals and data. Item usages, such as fuel, may flow through a system and be stored by a system. An item may have attributes (see 7.7 ), states (see 7.18 ), and nested item usages.

An item that performs actions is normally modeled as a part (see 7.11 ). All parts are items, but not all items are necessarily parts. An item may also be considered to be a part during some time slices of its lifetime but not others. For instance, an engine being assembled can be modeled as an item moving along an assembly line. However, once the engine assembly is completed, the engine can be considered to be a part that may be installed into a car, where it is expected to perform the action providing power to propel the car. But later it may be removed from the car and again be considered only an inactive item in a junkyard.

Items may also have an extent in space as well as time. The shape of an item is its boundary in three-dimensional space. Items without shapes are closed enabling them to be boundaries of other items (for example, a two-dimensional sphere has no boundary, but it is the shape of a three-dimensional ball). The Geometry Domain Library (see 9.7 ) includes a model of basic kinds of geometric shapes that can be composed to construct compound spatial items.

An item can also identify other items as enveloping shapes, which are closed items that are the boundary of a hypothetical item occupying the same or larger space as the enveloped item. Some of these can be bounding shapes, which overlap the bounded item on all sides. The spatial boundaries of items can break into separate closed items, such as the inside and outside of an egg shell. These inner boundaries can be the boundary of a hypothetical item, the interior of which is a void of the item. Items with no voids are solid.

An item definition or usage (that is not of a more specialized kind) is declared as a kind of occurrence definition or usage (see 7.9.2 ), using the kind keyword item. An item usage must only be defined by item definitions (of any kind) or KerML structures (see [KerML, 7.4.4]). The default multiplicity of an item usage is [1..1], under the conditions described in 7.6.3 .

item def Fuel {
    attribute pressure : PressureValue;
    ref item impurities[0..*] : Material;
}

The base item definition and usage are Item and items from the Items library model (see 9.2.3 ). (For other semantic constraints on item usages, see 8.4.6 ).

Metamodel references:

• Textual notation,  8.2.2.11
• Graphical notation, 8.2.3.11
• Abstract syntax,  8.3.11
• Semantics, 8.4.7

A part definition represents a modular unit of structure such as a system, system component, or external entity that may directly or indirectly interact with the system. A part definition is a kind of item definition (see  7.10 ) and, as such, defines a class of part objects that are occurrences with temporal (and possibly spatial) extent. A part usage is a kind of item usage that is a usage of one or more part definitions, but may also be a usage of item definitions that are not part definitions. This allows a part to be treated like an item in some cases (e.g., when an engine under assembly flows through an assembly line) and as a part in other cases (e.g., when an assembled engine is installed in a vehicle).

A system is modeled as a composite part, and its part usages may themselves have further composite structure. The parts of a system may have attributes (see 7.7 ) that represent different performance, physical and other quality characteristics. The parts may have ports (see  7.12 ) that define the points at which those parts may be interconnected (see 7.13 and 7.14 ). Parts may also perform actions (see  7.17 ) resulting in items flowing across the connections between them, and exhibit states (see 7.18 ) that enable different actions.

A part can represent any level of abstraction, such as a purely logical component without implementation constraints, or a physical component with a part number, or some intermediate abstraction. Parts can also be used to represent different kinds of system components such as hardware components, software components, facilities, organizations, or users of a system. 

A part definition or usage (that is not of a more specialized kind) is declared as a kind of occurrence definition or usage (see 7.9.2 ), using the kind keyword part. As a kind of item usage (see  7.10 ), a part usage must only be defined by item definitions (including part definitions) or KerML structures (see [KerML, 7.4.4]). The default multiplicity of a part usage is[1..1], under the conditions described in 7.6.3 .

item def Person;
part def Vehicle {
    ref part driver[0..1] : Person;
    part engine : Engine;
    part wheels[4] : Wheel;
}

The base part definition and usage are Part and parts from the Parts library model (see 9.2.4 ). (For other semantic constraints on part usages, see 8.4.7 ).

Note. Because the base usage of a part usage is the part usage parts defined by the base part definition Part, every part usage is always directly or indirectly defined by at least one part definition, implicitly if not explicitly, in addition to any other item definitions.

Metamodel references:

• Textual notation,  8.2.2.12
• Graphical notation, 8.2.3.12
• Abstract syntax,  8.3.12
• Semantics, 8.4.8

A port definition is a kind of occurrence definition (see  7.9 ) that defines a connection point to enable interactions between occurrences (most commonly parts). A port usage is a kind of occurrence usage definition that is a usage of a port definition.

A port usage may be connected to one or more other port usages (see  7.14 ). Such connections enable interactions between the occurrences that own the ports. The features of the port usages (whether inherited from its definition or declared locally for the usage) specify what can be exchanged in such interactions. Since ports are themselves kinds of occurrences, port definitions and usages can contain nested port usages.

A feature of a port may be directed, with one of the directions in, out, or inout (see also 7.6.3 ). Flows nested in a connection between ports may be used to model transfers between matching directed features of the ports (see 7.16 ). Two features match if they have conforming definitions and either both have no direction or they have conjugate directions. The conjugate of direction in is out and vice versa, while direction inout is its own conjugate. A transfer can occur from the out features of one port usage to the matching in features of connected port usages. Transfers can occur in both directions between matching inout features. Two ports are said to conform if each feature of one port has a matching feature on the other port. In this case, if the two ports are connected, it is possible to have a flow between every directed feature of one port and the matching feature on the other port. Bindings can also be used to relate features of connected ports (see 7.13.3 ).

Each port definition has a conjugated port definition whose directed features are conjugate to those of the original port definition. A conjugated port usage is a usage of a conjugated port definition. A conjugated port usage automatically conforms to a usage of the corresponding original port definition.

A port definition or usage is declared as a kind of occurrence definition or usage (see 7.9.2 ), using the kind keyword port. A port usage must only be defined by port definitions. The default multiplicity of a port usage is [1..1], under the conditions described in 7.6.3 . All the features of a port definition or port usage, other than any nested port usages, must be referential (non-composite).

port def FuelingPort {
    attribute flowRate : Real;
    out fuelOut : Fuel;
    in fuelReturn : Fuel;
}
part def FuelTank {
    port fuelOutPort : FuelingPort;
}

The base port definition and usage are Port and ports from the Ports library model (see 9.2.5 ). (For other semantic constraints on port usages, see 8.4.8 .)

Every port definition also implicitly declares a single, nested conjugated port definition, which has the same features as its original port definition, except that any directed features have conjugated directions (i.e., in and out are reversed, with inout unchanged). The name of the conjugated port definition is always given by the name of the original port definition with the character ~ prepended, in the namespace of the original port definition. For example, if a port definition has the name P, then its conjugated port definition has the name P::'~P'.

A conugated port usage is a shorthand for declaring a port usage defined by a conjugated port definition. With this shorthand, rather than using the actual name of the conjugated port definition, the name of the original port definition can be used, preceded by the symbol ~. For example,

port p : ~P;

is equivalent to

port p : P::'~P';

Since the symbol ~ is not considered part of a name when used in a conjugated port usage, it does not have to be placed within quotes, while quotes do have to be used to represent the actual name of the conjugated port definition as a lexical unrestricted name (see 7.2.2 ). Note that, if the original port definition itself has a name that is itself lexically represented as an unrestricted name, such as 'P-1', then its conjugated port definition has the (qualified) name 'P-1'::'~P-1', but the corresponding conjugated port usage is

port p1 : ~'P-1'

where the ~ is not placed inside the quotes.

Metamodel references:

• Textual notation,  8.2.2.13
• Graphical notation, 8.2.3.13
• Abstract syntax,  8.3.13
• Semantics, 8.4.9

Connection Definition and Usage

A connection definition is both a relationship and a kind of part definition (see 7.11 ) that classifies connections between related things, such as items and parts. Unless it is abstract, at least two of the owned features of a connection definition must be connection ends, which specify the things that are related by the connection definition. Connection definitions with exactly two connection ends are called binary connection definitions, and they classify binary connections.

The features of a connection definition that are not connection ends characterize connections separately from the connected things. Since a connection is a part, values of these non-end features can potentially change over the lifetime of the connection. However, the values of connection ends (i.e., the things that are actually connected) do not change over time (though they can potentially be occurrences that themselves have features whose values change over time).

A connection usage is a part usage (see 7.11 ) that is a usage of a connection definition, connecting usage elements such as item and part usages. A connection usage redefines the connection ends from its definition, associating those ends with the specific usage elements that are to be connected. For example, a connection definition could have connection ends that are part usages defined by part definitions Pump and Tank. A usage of this connection definition would then associate corresponding connection ends with specific pump and tank part usages. Supposing that the pump and tank part usages have multiplicity 1, then this means that the single value of the pump usage is to be connected to the single value of the tank usage.

A connection usage that connects parts is often a logical connection that abstracts away details of how the parts are connected. For example, plumbing that includes pipes and fittings may be used to connect a pump and a tank. It is sometimes desired to model the connection of the pump to the tank at a more abstract level without including the plumbing. This is viewed as a logical connection between the pump and the tank.

Alternatively, the plumbing can be modeled as a part (informally referred to as an interface medium) where the pump connects to the plumbing, and the plumbing connects to the tank. As a part itself, a connection can contain the plumbing either as a composite feature, or as a reference to the plumbing that is owned by a higher level pump-tank system context. In this way, the logical connection without structure can be transformed into a physical connection.

Bindings and Successions

Bindings and successions are special kinds of connections. They are usages, but, unlike regular connection usages, they are not part usages. The connections specified by bindings and successions are not occurrences and are not created and destroyed. Rather, they assert specific relationships between the features that they connect, which must be true at all times.

A binding is a binary connection that requires its two related usages to have the same values. A binding can also be used to bind a referential feature in one context to a composite feature in another context to assert they are the same thing. For example, the steering wheel in a car may be considered part of the interior of the car, while at the same time it is considered part of the steering subsystem. The steering wheel can be a composite part usage of the interior, and a reference part usage of the steering subsystem, and these two usages can be bound together to assert that they are the same part.

A feature value is a shorthand for initializing or binding a usage to the result of an expression (see 7.19 ) as part of the declaration of the usage. There are two types of feature value binding.

• A fixed feature value establishes the binding of the usage to the result of evaluating the given expression at the point of declaration of the usage. Such a binding cannot be overridden in a redefinition of the usage because, once asserted, a binding must be true for all instances of the usage.
• A default feature value also includes an expression, but it does not immediately establish the binding of the usage. Instead, the evaluation of the expression and the binding of the usage is delayed until the instantiation of a definition or usage that features the original usage. Unlike a fixed feature value, a default feature value can be overridden in a redefinition of its original feature with a new feature value (fixed or default). In this case, the new overriding feature value is used instead of the original feature value for binding the redefining usage.

A succession is a binary connection that requires its two related usages to have values that are occurrences that happen completely separated in time, with the first occurrence happening before the second. Successions can be used to assert the ordering of any kind of occurrences in time, but are particularly useful for event occurrences (see 7.9 ) and performances of actions (see 7.17 ).

A connection definition or usage (that is not of a more specialized kind) is declared as a kind of occurrence definition or usage (see 7.9.2 ), using the kind keyword connection. A connection usage must only be defined by connection definitions (of any kind) or KerML association structures (see [KerML, 7.4.5]). Unless it is abstract, a connection definition or usage must have at least two end features (which may be owned or inherited). A binary connection definition or usage is one that has exactly two end features.

End features are declared as usages (see 7.6.3 ), prefixed by the keyword end. End features are always considered referential (non-composite), whether or not their declaration explicitly includes the ref keyword. The end features of a connection definition or usage identify the participants in the connections that are instances of the connection definition or usage and must have multiplicity 1..1. If a multiplicity is not explicitly declared for an end feature, then a default of 1..1 is implicitly declared for it (regardless of the usual conditions for default multiplicity given in 7.6.3 ).

Connection definitions and usages are also relationships. For a connection definition, its related elements are given by the definitions of its end features. For a connection usage, its related elements are the features associated to each of its end features via reference subsetting relationships, whose textual notation is the keyword references or the equivalent symbol ::>. (See also 7.2 on Relationships.)

// The related elements of this connection definition
// are the part definitions Hub and Device.
connection def DeviceConnection {
    end part hub : Hub;
    end part device : Device;
    
    // This is a non-end feature of the connection definition.
    attribute bandwidth : Real;
}

// The related elements of this connection usage
// are the part usages mainSwitch and sensorFeed.
connection connection1 : DeviceConnection {
    end part hub ::> mainSwitch[1];
    end part device ::> sensorFeed[1];
}

The kind keyword (e.g., part in the example above) may be omitted from an end declaration unless it has an owned cross feature, as described later). In this case, the end feature is a reference usage by default (i.e., as if ref was used as the kind keyword).

For a binary connection definition or usage, one or both end features can be explicitly declared to subset a cross feature owned by the other related type. This is done with cross subsetting, which is a special kind of subsetting relationship specified using the keyword crossing or the symbol =>. Only end features may have cross subsetting relationships, and an end feature can have at most one owned cross subsetting.

part def Hub {
    ref part connectedDevices [1..*] ordered : Device;
}
part def Device {
    ref part connectingHub [0..1] : Hub;
}
connection def DeviceConnection {
    end part hub : Hub crosses device.connectingHub;
    end part device : Device => hub.connectedDevices;
    attribute bandwidth : Real;
}

This specifies that each instance of the DeviceConnection connection definition must link a value of the connectingHub feature of the device with a value of the connectedDevices feature of the hub. That is, creating a DeviceConnection between a Hub and a Device means that the Device must be one of the connectedDevices of the Hub and that the Hub must the connectingHub of the Device. As shown above, the target of a cross subsetting relationship must be a feature chain (see 7.6.6 ) in which the first feature is the other connection end and the second feature is the cross feature for that end.

Cross feature multiplicity effectively constrains the number of instances of a connection definition. It applies to each set of instances (connections) of the connection definition that have the same (single) values for each of the other ends. For a binary connection definition, this is the same as the number of values resulting from "navigating" across the association from an instance of one related type to instances of the other related type. Cross feature uniqueness and ordering apply to the instances navigated to, preventing duplication among them and ordering them to form a sequence.

For example, given a specific Device, navigating across all DeviceConnections with that Device as the device to the corresponding hub gives a collection of Hubs that must be the same as the connectingHub of the Device. The connectingHub feature has a multiplicity of 0..1, requiring that there must be at most one DeviceConnection for any Device. Similarly, given a specific Hub, navigating across all DeviceConnections with that Hub as the hub to the corresponding device gives a collection of Devices that must be the same as the connectedDevices of the Hub. The connectedDevices feature has a multiplicity lower bound of 1, requiring that there must be at least one DeviceConnection for every Hub. The declaration of connectedDevices as ordered means that this collection is ordered in the same order as the connectedDevices of the Hub. Similarly, if connectedDevices were non-unique, the collection could contain duplicate Devices.

Note that these semantics depend on the values of cross features being exclusively due to the existence of corresponding connections. In particular, cross features can only meet their minimum multiplicity constraints if such connections exist. For example, a Hub having a Device as one of its connectedDevices is sufficient to require that a DeviceConnection exists between that Hub and that Device, and, therefore, that the Hub is also the connectingHub of the Device. In addition, since connectedDevices has a multiplicity lower bound of 1, there must be at least one DeviceConnection for every Hub (as stated above), to provide the required value for connectedDevices.

It is also possible to declare cross features directly in the declaration of the ends of a connection definition, rather than nested in the related types of the connection definition. Such owned cross features are declared between the end and kind keywords of the association end declarations (and, in this case, the kind keyword is required). These may be full usage declarations, including declared name and or short name, owned subsettings and redefinitions, etc., but without bodies and nested elements (see 7.6.3 on usage declaration).

connection def HubDeviceConnection {
   end connectingHub [0..1] ordered part hub : Hub;
   end connectedDevices [1..*] part device : Device;
   attribute bandwidth : Real;
}

Note. Owned cross features are in the namespace of the owning end features, so their names are qualified by the name of the end features, e,g., HubDeviceConnection::hub::connectedDevices.

For a binary connection definition, an owned cross feature is implied to be featured by the type of the other association end, rather than its owning connection end. Further, a connection end with a cross feature has an implied cross subsetting relationship to the cross feature through the other end feature. This ensures owned cross features have the same semantics as cross features that are nested directly in the related types of the connection end. (For further details, see 8.4.9.1 on connection definition semantics.)

Note. If an end feature has an owned cross feature, then it may not have an explicit cross subsetting relationship declared to an unowned cross feature.

While owned cross features can have full feature declarations, it is often sufficient to just include the cross multiplicity, ordering, and/or uniqueness on one or more connection ends.

connection def HubDeviceConnection {
    end [0..1] part hub : Hub;
    end [1..*] ordered part device : Device;
    attribute bandwidth : Real;
}

This specifies that every Device must have at most one Hub as its hub, and that every Hub may have one or more Devices as connectedDevices, which are ordered. Note that the connection ends themselves, as participants of the connection, still always have multiplicity 1..1, whether or not this is included in the declaration.

Cross features can also be used in connection definitions with more than two ends, but they must all be owned by the connection ends. In general, the cross multiplicity, ordering, and uniqueness of a connection end apply to the the collection of its values from each set of instances of the connection definition that have the same (single) values for each of the other ends.

connection def ProtocolDeviceConnection {
    end [*] part hub : Hub;
    end [*] ordered part device : Device;
    end [0..1] item protocol : Protocol;
}

The cross multiplicity 0..1 for protocol requires that, for every pair of a Hub and a Device, at most one ProtocolDeviceConnection instance may connect that Hub as its hub and Device as its device to a Protocol as its protocol. Similarly, every pair of a Hub as hub and a Protocol as protocol may be connected to any number of Devices as device, including none at all, as declared by the cross multiplicity of device. This collection of connected Devices is ordered, as declared by the cross ordering of device. The same applies to the cross multiplicity of hub. (For further details, see 8.4.9.1 on connection definition semantics.)

Connection usages may also have end features with cross features, either specified using cross subsetting or as owned cross features. The cross feature for the end feature further constrains any inherited cross feature(s).

part def NetworkConfiguration {
    part networkHubs[*] : Axle;
    part networkDevices[*] : Device;
    // Connects each one of the networkHubs to at most four of the networkDevices.
    connection networkConnections : DeviceConnection {
        end [1] part hub references networkHubs;
        end [0..4] part device references networkDevices;
    }
}

There are two shorthand textual notations for connection usages.

Rather than using explicit end feature declarations in the body of a connection usage, the related features of the connection usage may be identified in a comma-separated list, between parentheses (...), preceded by the keyword connect, placed after the connection usage declaration and before its body. The identification of a related feature may optionally be preceded by a cross multiplicity and/or an end feature name followed by the keyword references or the symbol ::>. If the declaration part of the connection usage is empty when using this notation, then the keyword connection may be omitted.

connection connection1 : DeviceConnection connect (
    [1] hub ::> mainSwitch[1], [1] device ::> sensorFeed
);

// This is a ternary connection.
// It is equivalent to "connection connect (axle, wheel1, wheel2);"
connect (axle, wheel1, wheel2);

If the connection usage is binary, then a further special notation may be used in which the source related feature is identified directly after the keyword connect and the target related feature is identified after the keyword to. As above, if the declaration part of the connection usage is empty, then the keyword connection may be omitted.

connection connection1 : DeviceConnection 
    connect [1] hub ::> mainSwitch to [1] device ::> sensorFeed;

connect leftWheel to leftHalfAxle;

The base connection definition and usage are Connection and connections from the Connections library (see 9.2.6 ). For a binary connection definition or usage, the base definition and usage are further restricted to BinaryConnection and binaryConnections, which enforce that the connection has exactly two ends.

If a connection definition has a single owned superclassification relationship with another connection definition, it may inherit end features from this general connection definition. However, if it declares any owned end features, then each of these must redefine an end feature of the general connection definition, in order, up to the number of end features of the general connection definition. If no redefinition is given explicitly for an owned end feature, then it is considered to implicitly redefine the end feature at the same position, in order, of the general connection definition, if any. An implicitly or explicitly redefining connection end may also further constrain the cross multiplicity (if any) of the superclassifier connection ends that it redefines.

// Implicitly specializes Connections::BinaryConnection by default.
connection def AssetOwnership {
    attribute valuationOnPurchase : MonetaryValue;
    end [1..*] item owner : LegalEntity; // Implicitly redefines BinaryConnection::source.
    end [*] item ownedAsset : Asset; // Implicitly redefines BinaryConnection::target.
}
connection def SoleOwnership specializes AssetOwnership {
    end [1] item owner; // Implicitly redefines Ownership::owner.
    // ownedAsset is inherited.
}

Any specialization of a binary connection definition must also be binary. That is, it can inherit or redefine the two end features from the general connection definition, but it cannot add more end features.

If a connection definition has more than one owned superclassification with other connection definitions, then it must declare a number of owned end features at least equal to the maximum number of end features of any of the general connection definitions. Each of these owned end features must then redefine the corresponding end feature (if any) at the same position, in order, of each of the general connections, either explicitly or implicitly.

Similar rules hold for the end features of a connection usage that is defined by one or more connection definitions and/or subsets or redefines one or more connection usages.

connection connection1 : DeviceConnection {
    end [1] part hub ::> mainSwitch; // Implicitly redefines DeviceConnection::hub.
    end [1] part device ::> sensorFeed; // Implicitly redefines DeviceConnection::device.
}

A binding can be declared as a usage as described in 7.6.3 , using the kind keyword binding. Note that a binding is not a kind of occurrence usage (unlike a regular connection usage), so the notations for time slices, snapshots and individuals (described in 7.9 ) do not apply to it. Further, the two related features of a binding are specified using a special notation.

The two related features of a binding are identified after its declaration part and before its body, following the keyword bind and separated by the symbol =. If the declaration part is empty, then the keyword binding may be omitted.

part def Vehicle {
    part fuelTank {
        out fuelFlowOut : Fuel;
    }
    part engine {
        in fuelFlowIn : Fuel;
    }
    binding fuelFlowBinding
        bind fuelTank.fuelFlowOut = engine.fuelFlowIn;

    // The following is equivalent to the above, but
    // without the name.
    bind fuelTank.fuelFlowOut = engine.fuelFlowIn;
}

The base usage for a binding is the the KerML feature selfLinks from the Links model in the Kernel Semantic Library (see [KerML, 9.2.3]).